Such environments may include L2 over L3 packet communication protocols for transporting Layer 2 data units over Layer 3 data units. For example, the Linux operating system was recently extended to include an IETF specified Ethernet over UDP protocol known as VxLAN.
The VxLAN protocol is described by an IETF draft entitled “VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks” (referenced draft-mahalingam-dutt-dcops-vxlan-08, and available at http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-08), which has not been finalized yet.
The VxLAN processing is instantiated on Linux using a L2 over one or several UDP terminations into the Linux kernel, then these terminations of UDP packets lead to processing the packets through Linux logical interfaces (also referred to as netdevices) which are the management entities of VxLAN.
To handle incoming VxLAN packets, the Linux kernel opens an UDP socket to receive all packets with a destination address and an UDP port of one of the configured VxLAN interfaces. Then, the Linux kernel checks the VxLAN Network Identifier to find the proper VxLAN interface.
If the feature IFLA_VXLAN_LEARNING has been set, the Linux kernel checks if there is an entry into the forwarding database (FDB) for the inner source MAC address of the VxLAN packet. If not, the Linux kernel updates the FDB database.
After that, the packet is decapsulated (VxLAN header is removed and ECN status is updated accordingly) and injected again into the networking stack of the Linux kernel.
When the Linux kernel needs to send a packet via a VxLAN interface, it calls a transmit (xmit) function of the VxLAN driver.
If the feature IFLA_VXLAN_PROXY has been set and the packet is an ARP packet, the Linux kernel checks its ARP or NDP neighbour table, then it builds an ARP or respectively a NDP reply packet [NEIGHBOR REPLY] if an entry is found else, if the feature IFLA_VXLAN_L3MISS has been set, it notifies the Linux userland with a Netlink message RTM_GETNEIGH [L3MISS NOTIFICATION]. In any case, the packet is dropped.
The Linux kernel VxLAN receive function look up into its forwarding database in order to retrieve the corresponding VxLAN tunnel end points that had been configured. The lookup is done with the destination MAC address of the packet.
If a forwarding entry is found into the FDB and this forwarding entry is marked as a router (NTF_ROUTER) and the feature IFLA_VXLAN_RSC (route short circuiting) has been set, the Linux kernel checks its ARP or NDP table (based on the destination IP address):                if an neighbor entry is found, the Linux kernel updates the source and destination MAC addresses of the packet and it performs a new look up from the forwarding database with the new destination MAC address. Then it continues with the following processing steps [STEP_NOFOUND].        if no neighbor entry is found and the feature IFLA_VXLAN_L3MISS has been set, the Linux kernel sends a Netlink notification RTM_GETNEIGH [L3MISS NOTIFICATION] to the userland. A userland process may listen to this [L3MISS NOTIFICATION] and update the Linux kernel ARP or NDP tables.        if no neighbor entry is found and the feature IFLA_VXLAN_L3MISS has not been set, the fast path [DATAPLANE] continues with the below steps [STEP_NOFOUND].        
If no forwarding entry is found [STEP_NOFOUND] for the destination MAC address of the packet, the Linux kernel performs a second look up with a zero MAC address (00:00:00:00:00:00):                if no forwarding entry is found, the packet is dropped. If the feature IFLA_VXLAN_L2MISS is set, the Linux kernel sends a Netlink notification RTM_GETNEIGH [L2MISS NOTIFICATION] to the userland before dropping the packet. A userland process may listen to this [L2MISS NOTIFICATION] and update the Linux kernel forwarding database.        if a forwarding entry is found, the Linux kernel encapsulates (add the VxLAN headers and inherit of the TOS field, depending on the interface parameters) and then it sends a copy of the packet for each VxLAN tunnel end points (VTEP) that are into this FDB entry.        
The challenge of a Linux-based OS processing for VxLAN packets is performance in terms of the number of processed packets per second.
Another drawback of the Linux-based OS processing for VxLAN packets relates to the number of CPU cycles consumed for processing each VxLAN packet: each processed packet uses a minimum number of CPU cycles, even though some hardware offloads, such as offload for the checksum, encapsulation/decapsulation, segmentation/reassembly, may be used.
There is therefore a need for providing a method for processing VxLAN packets in an environment controlled by an operating system with improved performances.